>>>>> "hobbit" == hobbit <Hobbit> writes: hobbit> Why in all this telnetd flap has nobody mentioned that hobbit> /bin/login should be relinked STATICALLY? That at least hobbit> defers the LD_* class of problem until after login has hobbit> done the setuid and exec, but still leaves things like IFS hobbit> passed to scripts. This point has been mentioned to me several times, and I've sort of publically ignored it because I don't consider it particularly valid. It is an acceptable temporary fix to the problem, and if you have source to login but not telnetd, by all means use it. I really hope, however, that vendors don't start linking login statically unless they start shipping source with their OS. This makes it impossible to fix bugs like syslog(3) by patching shared libraries. In addition, depending on linker features like static binding is bad policy; to the extent that it is possible, programs should be secure, independent of any build procedure or enhanced security features of a particular OS. I certainly think the idea of statically linking all network applications is a bad idea. Most network applications don't call exec() so the libary issue is not likely to matter. Of those that do, only httpd, telnetd, to a limited extend rlogind, and possibly a few others accept environment variables. Besides, as you hint, the potential for trouble is much broader than LD_*; any environment variable used by libc could be a potential target. I think that this entire problem stresses the importance of clearly defining the interface between trusted programs like login and their users. If the documentation for login mentioned the dependence on LD_*, the assumption that -f was valid if the uid==0, etc, several security holes over the past few years would have been discovered and fixed much sooner. I understand that issues like LD_* are implicit in any dynamic executable, but I argue that good documentation in login would clearly point out to implementers of programs that call login how to use it without violating its assumptions. --Sam hobbit> Still, my own rule of thumb is that any binary that talks hobbit> to the net, handles inbound connections, handles hobbit> authentication, etc ... should not be depending on shared hobbit> libs. It's well worth the miniscule disk space hit. hobbit> Vendors, LISSEN UP. hobbit> _H*